Network security breaches hinder the application of distributed computing systems manifested as the Grids, clusters, intranets, extranets or P2P systems. Particularly, P2P streaming systems often assume that hosts are cooperative. However, this may not be true in the open environment of the INTERNET.
Peer-to-peer (P2P) communication, and in fact all types of communication, depend on the possibility of establishing valid connections between selected entities. However, entities may have one or several addresses that may vary because the entities move within the network, the topology changes or/and address lease cannot be renewed. A classic architectural solution to this addressing problem is thus to assign to each entity a stable name, and to “resolve” this name to a current address when a connection is needed. This name to address translation must be very robust and it must also allow for easy and fast updates.
To increase the likelihood that an entity's address may be found by those seeking to connect to it, many peer-to-peer protocols, including the Peer Name Resolution Protocol (PNRP), allow entities to publish their address through various mechanisms. Some protocols also allow a client to acquire knowledge of other entities' addresses through the processing of requests from others in the network. Indeed, it is this acquisition of address knowledge that enables successful operation of peer-to-peer networks. That is, the better the information about other peers in the network, the greater the likelihood that a search for a particular resource will converge.
However, without a robust security infrastructure underlying the peer-to-peer protocol, malicious entities can easily disrupt the ability for such peer-to-peer systems to converge. Such disruptions may be caused, for example, by an entity that engages in identity theft. In such an identity theft attack on the peer-to-peer network, a malicious node publishes address information for identifications (IDs) with which it does not have an authorized relationship, i.e. it is neither the owner nor a group member, etc. A malicious entity could also intercept and/or respond first before the good node responds, thus appearing to be the good node.
Commonly, P2P network attacks may attempt to disrupt or exhaust node or network resources. In PNRP, a malicious entity could also obstruct PNRP resolution by flooding the network with bad information so that other entities in the network would tend to forward requests to nonexistent nodes (which would adversely affect the convergence of searches), or to nodes controlled by the attacker. PNRP's name resolution ability could also be degraded by modifying the RESOLVE packet used to discover resources before forwarding it to a next node, or by sending an invalid RESPONSE back to the requester that generated the RESOLVE packet. A malicious entity could also attempt to disrupt the operation of the peer-to-peer network by trying to ensure that searches will not converge by, for example, instead of forwarding the search to a node in its cache that is closer to the ID to aid in the search convergence, forwarding the search to a node that is further away from the requested ID. Alternatively, the malicious entity could simply not respond to the search request at all. The PNRP resolution could be further hampered by a malicious node sending an invalid BYE message on behalf of a valid ID. As a result, other nodes in the cloud will remove this valid ID from their cache, decreasing the number of valid nodes stored therein.
While simply validating address certificates may prevent the identity theft problem, this is ineffective against an attack that impedes PNRP resolution. An attacker can continue to generate verifiable address certificates (or have them pre-generated) and flood the corresponding IDs in the peer-to-peer cloud. If any of the nodes attempts to verify ownership of the ID, the attacker would be able to verify that it is the owner for the flooded Ids because, in fact, it is. However, if the attacker manages to generate enough Ids it can bring most of the peer-to-peer searches to one of the nodes it controls. Once a malicious node brings the search to controlled node, the attacker fairly controls and directs the operation of the network.
A malicious node may also attempt a denial of service (DoS) attack. When a P2P node changes, it may publish its new information to other network nodes. If all the nodes that learn about the new node records try to perform an ID ownership check, a storm of network activity against the advertised ID owner will occur. Exploiting this weakness, an attacker could mount an internet protocol (IP) DoS attack against a certain target by making that target very popular. For example, if a malicious entity advertises an Internet Website IP address as the updated node's ID IP, all the nodes in the peer-to-peer network that receive this advertised IP will try to connect to that IP to verify the authenticity of the record. Of course, the Website's server will not be able to verify ownership of the ID because the attacker generated this information. However, the damage has already been done. That is, the attacker convinced a good part of the peer-to-peer community to flood the IP address with validation requests and may have effectively shut it down.
In US 2003/0226033 is described a method based on the main step that when a program is received by a computer system, whether through introduction by a user or from a peer computer system, the computer system queries a database of blacklisted programs. If the received program is found in the blacklist database, the computer system does not allow the received program to run. If the received program is not found in the blacklist database, the computer system scans the received program to determine whether the received program might cause an undesired behaviour if it were to run on the computer system. If the computer system determines that the received program could cause an undesired behaviour, the computer system adds the received program to the blacklist database and does not allow the received program to run on the computer system. But such a solution is rather very limited since is successful only for programs that are already blacklisted. It can not really detect a malicious peer.
In US 2006/0179139 is described a security infrastructure and methods are presented that inhibit the ability of a malicious node from disrupting the normal operations of a peer-to-peer network. The methods of the invention allow both secure an insecure identities to be used by nodes by making them self-verifying. When necessary or opportunistic, ID ownership is validated by piggybacking the validation on existing messages. The probability of connecting initially to a malicious node is reduced by randomly selecting to which node to connect. Further, information from malicious nodes is identified and can be disregarded by maintaining information about prior communications that will require a future response. Denial of service attacks are inhibited by allowing the node to disregard requests when its resource utilization exceeds a predetermined limit. The ability for a malicious node to remove a valid node is reduced by requiring that revocation certificates be signed by the node to be removed. Such a solution does not solve the problem entirely since the malicious node can still act i.e. is not somehow deactivated.
In US 2006/0215575 is described a solution based on the analysis of some statistics associated to the overall health of a P2P while that statistics are gathered and analyzed pertaining to individual node and node-to-node performance within the P2P network. When used with live P2P networks, the health statistic may provide a real-time view into network performance. Such a view may be used to adjust P2P network topology or to isolate underperforming or malicious nodes. But such a solution is based on supplementary hardwares like a controller and further instrumentations.
In the paper from Xing Jin et al. “Detecting malicious hosts in the presence of lying hosts in peer-to-peer streaming”, ICME 2006, pages 1537-1540, is discussed how to detect malicious hosts (e.g., with attacking actions and abnormal behaviour), based on their history performance. In the proposed system, each host monitors the performance of its neighbour(s) and reports this to a server. Based on the reports, the server computes hosts reputation with hosts of low reputation being malicious. A problem is that hosts may lie by submitting forged reports to the server. To overcome that problem is proposed in the paper from Xing Jin et al. to formulate the reputation computing problem in the process of lying hosts as a minimization problem and to solve it by the traditional Levenberg-Marquardt algorithm. But such solution is far to be satisfactory.